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Microsoft EEAP Release Notes 


Key Build validation and What's Bug Known Breaking 
information feedback new fixes issues changes 


Windows Server LTSC and SAC, preview build 17728.1000 


These release notes describe the new features, bug fixes, known issues, and breaking 
changes introduced since build 17723.1000 of Windows Server 2019 Long-Term Servicing 
Channel (LTSC). 


This build includes the following: 


Long-Term Servicing Channel (LTSC) preview 
e Windows Server 2019 Datacenter Edition and Standard Edition with Desktop Experience 
and Server Core installation options (ISO and VHDX) 


Semi-Annual Channel (SAC) preview 
e Windows Server Datacenter Edition and Standard Edition with Core installation options 
(ISO and VHDX) 


Additional content (LTSC and SAC) 
e Nano Server Container 
e Server Core Container 
e Microsoft Hyper-V Server preview 
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Key information 


This section has key information required for testing the latest build. 


Windows Server 
activation keys 


Symbols for 
debugging 


HLK and 
Certification 
Guidance 


This build and future builds require use of activation keys during setup. The 
following keys allow for unlimited activations. 


Datacenter 6XBNX-4JQGW-QX6QG-74P76-72V67 


Standard MFY9F-XBN2F-TYFMP-CCV49-RMYVH 


Note These activation keys are valid for preview builds only. After 
activation for the preview keys is disabled, you may install preview builds 
for development and testing purposes without activating. 


This Server Insider preview release build will expire on December 14, 2018. 


If you need symbols, you can obtain them from the public symbol server. For 
details, see Using the Microsoft Symbol Server. 


The Windows Hardware Lab Kit (HLK) will be updated to support Windows 10 
vNext and Windows Server 2019. 


The HLK is updated each week and available for download on Microsoft 
Collaborate, you will see the download locations with your weekly build 
notifications. 


The HLK for Windows 10 and Windows Server 2019 will enforce the Windows 
10 hardware requirements and policies, which will be posted on MSDN in 
March, and is designed for testing Windows 10 vNext and Windows Server 
2019. 


The support scenarios identified in the following table will be accepted. 
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WINDOWS 10 


DEVICE/COMPONENT 


SYSTEM 


VERSIONS SUBMISSIONS SUBMISSIONS 
HLK VERSION SUPPORTED ACCEPTED ACCEPTED 
"RS5" Code named "RS5" client "“vNext" Server 
"RS5" device/component systems 
Windows Server 
2019 
device/component 
1709 1709 - client 1709 client 1709 client 
device/component systems 
1703 1703 - client 1703 client 1703 client 
1607 - client device/component systems 
1607 client 
device/component 
1607 1607 - client 1607 client 1607 Server 


1607 - Server, 
Azure Stack, 
SDDC 

1511 - client 


device/component 
1607 Server 
device/component 
1511 client 
device/component 


systems 


When submitting a Windows 10 RS5 and Windows Server 2019 HLK package 
for validation, you must use Windows 10 vNext and Windows Server 2019, 
version build TBD or newer on the test device. The submission will otherwise 
be rejected. 


You must continue to use the Windows Hardware Certification Kit (HCK) 
version 2.1 to certify for following operating systems: 


e Windows 7 

e Windows 8 

e Windows 8.1 

e Windows Server 2012 

e Windows Server 2012 R2 


You must continue to use the Windows Logo Kit (WLK) version 1.6 to certify 
for following operating systems: 


e Windows Server 2008 R2 (x64 and ia64) 
e Windows Server 2008 (x86, x64 and ia64) 


Certification for Windows Server 2016, Azure Stack and SDDC must meet the 
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Installing kits 
on released 
operating 
systems 


Windows Hardware Compatibility Requirements as stated in version 1607 of 
the documentation, use the 1607 version of the Windows Server 2016 
operating system and use HLK version 1607 build 14393 with matching 
playlist and supplemental content to generate logs and following the policies 
stated in the Windows Server Policy. Questions about the Azure Stack or 
SDDC program or how to submit the results for solution validation should be 
directed to the appropriate Microsoft contact—a technical account manager 
or a partner management contact. 


If you are installing the Windows 10 kits on a publicly released OS such as 
Windows 10, version 1703, Windows 10, version 1607, Windows 10, 

version 1511, Windows 10, Windows 8.1, Windows 8, or Windows 7, you must 
disable strong name-signing and manually install two additional test 
certificates. To do this, perform the following installation procedure once for 
each test computer, using an account with administrator privileges on the 
controller computer: 


e From the KitPrelnstall folder, install the TestRoot.cer and TestRoot- 
SHA2.cer test certificates using the following steps: 


1. From the controller computer, right-click the certificate. 
2. Click Install Certificate. 

3. Click Next. 

4. Accept the default for the certificate store, and click Next. 
5. Click Finish. 


e From the same folder, disable strong name signing by installing the 
StrongNameBypass.reg and WOW64StrongNameBypass.reg registry 
keys, as follows: 


From the controller computer, right-click the registry key. 
Click Merge. 

Click Run. 

Click Yes. 


FW NS 
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Playlists to Due to the change in the policy regarding which versions of Windows 10 that 


support the the HLK validates, it is important to note which tests are required with each 
incremental kit. Playlists must match the version of the HLK being used, not the version of 
Windows Windows 10 that is under test. For RS5 and Windows Server 2019 Previews, 
releases the Preview Playlist is available on Collaborate at: 


https://partner.microsoft.com/en-us/dashboard/collaborate/packages/5393. 


The follow table lists the required playlist pairings. 


HLK 
VERSION ARCHITECTURE PLAYLIST 
"RS5" x86 or x64 HLK Version 1709 CompatPlaylist x86_x64 
"RS5" ARM64 HLK Version 1709 CompatPlaylist ARM64 
desktop HLK Version 1709 CompatPlaylist ARM64_x86 
on ARM64 
1709 x86 or x64 HLK Version 1709 CompatPlaylist x86_x64 
1709 ARM64 HLK Version 1709 CompatPlaylist ARM64 
desktop * HLK Version 1709 CompatPlaylist ARM64_x86 
on ARM64 
1703 x86 or x64 HLK Version 1703 CompatPlaylist 
1607 x86 or x64 HLK Version 1607 CompatPlaylist 


Testing ARM64 Desktop requires two playlists. For additional information, 
see the setup instructions in Step 1: Install Controller and Studio on the 
test server on Hardware Dev Center. 


Symbols for If you need symbols, you can obtain them from the public symbol server. For 
debugging details, see Using the Microsoft Symbol Server. 
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Build validation and feedback 


In each preview release, there are two major areas that we would like you to try out: 


e In-place OS Upgrade (from Windows Server 2012 R2, Windows Server 2016 or a 
previous preview build). 


e Application compatibility — please let us know if any server roles or applications stops 
working or fails to function as it used to. 


Please report any issues you find. 


In addition, please also validate functionality that was introduced in previous preview 
releases. For a list of new features introduced in earlier releases, see aka.ms/Server|nsider- 
WhatsNew. 


As always, we welcome your feedback. 


What's new 


This section describes some of the new features that are in this build. 


Congestion Control with LEDBAT 


Keeping a network secure is a never-ending job for IT pros, and doing so requires regularly 
updating systems to protect against the latest threat vectors. This is one of the most common 
tasks that an IT pro must perform. Unfortunately, it can result in dissatisfaction for end users, 
because the network bandwidth used for the update can compete with interactive tasks that 
end users need for them to be productive. 


With Windows Server 2019, we bring a latency-optimized, network congestion control 
provider, called LEDBAT, that scavenges whatever network bandwidth is available on the 
network, and uses it. 
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For all the details about this improvement, please see the Networking Blog: 
Top 10 Networking Features in Windows Server 2019: #9 LEDBAT —- Latency Optimized 
Background Transport. 


Failover Cluster: Cluster Network Name 


The Cluster Network Name (CNO) in a failover cluster is crucial to the management of a 
cluster. When creating a cluster, the creation process will detect the IP address scheme that 
is used on the network cards. If your network uses DHCP, the Cluster IP address will 
automatically get an IP address from your DHCP server. If your network uses static IP 
addresses, you will be prompted to enter an IP address to be used. However, there are only 
so many IP addresses that may be available, so we have introduced new functionality that is 
available when creating a cluster and the Cluster Network Name. 


You may be familiar with how a Scale-Out File Server (SOFS) works—an SOFS has a separate 
network name, but it is a distributed name. That means that the network name will take on 
the IP address of all the nodes. So, in DNS you can see the SOFS network name with an entry 
that is the IP address of the physical (or virtual) nodes. The system now offers that as an 
option for the Cluster Network Name and will do some detection to make things a little 
easier, depending on how and where you create it. 


There is a new switch for Failover Cluster PowerShell cmdlet switch called - 
ManagementPointNetworkType that can now be used with New-Cluster. The options for 
this switch are: 


e Singleton: Use the traditional method of DHCP or static IP address. 

e Distributed: Use a Distributed Network Name using node IP addresses. 

e Automatic: Use detection. If running in Azure, use Distributed; if running on premises, 
use Singleton (the default). 


So, for example, to create a cluster utilizing Node1 and Node2 on-premises, where DHCP 
provides IP addresses, and to have it as a distributed name, the PowerShell command would 
be: 


New-Cluster -Name Cluster -ManagementPointNetworkType Distributed -Node 
Node1,Node2 
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If you use Failover Cluster Manager to create the cluster, it will default to using Automatic for 
the network type. 


This makes creating clusters in Azure a much easier process, because there is no need to 
create an additional Internal Load Balancer (ILB) for the Failover Cluster. 


(A) Cluster Core Resources 


Distributed Server Name 
=, Name: NoClusterlP (#) Online 


Bug fixes 


The bug fixes described in the following table are new in this build. 


WORK ITEM DESCRIPTION OF BUG FIX 


18321091, We resolved an issue that could cause Deployment Image Servicing and 
18422316 Management (DISM) to fail when multiple features are enabled via an answer 
script (unattend.xml) due to premature verification of feature state. 


18198106, We resolved an issue that could cause Windows Security to crash when a user 
18236533 clicks Manage providers on Virus & threat protection in Settings. 
17560221, We resolved an issue that caused Microsoft Edge to ignore preload="none" 
16679177 when a src attribute for an HTML5 video was added dynamically. 

14972457 We closed this bug as not reproducible: The Virtual Machine Management 


Service (VMMS) may experience an error, 
APPLICATION_FAULT_INVALID_POINTER_READ, in Cluster Manager. 


18048332, We fixed the following issue: Draining a node may fail with an error: "Cannot 
17942071 create a file when that file already exists. (0x800700b7)." 
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WORK ITEM DESCRIPTION OF BUG FIX 


18062489 We fixed the following issue: Preview releases of the operating system, starting 
with build 17698, may fail to detect a specific family of RAID controllers. 


18134917, We fixed the following issue: Virtual machines stop unexpectedly with exit reason 
18299671 3, and they migrate repeatedly every few minutes. 
17969018 We advise customers to work around this issue: A specific distributed search and 


analytics engine may by denied access when querying C:\Windows\temp\ as 
ContainerUser. 


To work around this issue, set the paths for temporary folders to another 
location. For example, by using setx: 

setx /M TEMP "c:\sample" 

setx /M TEMP "c:\sample" 


18243152 We fixed the following issue: On Nano Server, copying a file from an SMB volume 
in a container to local storage fails. 


Known issues 


The following known issues are new in this build, or they were not resolved in the last build. 
WORK ITEM _— DESCRIPTION OF KNOWN ISSUE 


18314155 [NEW] When a Windows Defender Application Guard container crashes, the 
resulting type of dump may be unexpected. 


18368759 [NEW] When using the Virtual Machine Management Service (VMMS), 
configuration of a cluster resource may fail during a node drain operation. 


17628180 [NEW] On a preview build of the operating system, Narrator is not available by 
default after installation. On an affected system, the audio service is disabled by 
default. 
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WORK ITEM 


18381990 


18329790 


18321045, 
18306015, 
18098973, 
18321007 


18198732 


17033455 


DESCRIPTION OF KNOWN ISSUE 


A Multi-Resilient Volume (MRV) may fail to mount during node maintenance for 
a software-defined datacenter (SDDC) cluster, causing virtual machines to go 
offline. 


Services.exe should not launch Upfc.exe when a system starts if the system is 
running inside of a container. 


On recent preview builds, database applications might not be able to initialize a 
database and fail with a stack overflow or insufficient privileges when the 
database is located on an SMB volume. 


Shielded VMs running Linux do not boot. The loader (LSVMLoad) waits for a 
passphrase for the boot partition. 


Creating or modifying environment variables by using setx fails on a system 
running in a Nano Container (that is, Nano Server as a container image). On an 
affected system, setx requires a specific path in the registry, HKCU\Environment\, 
to exist by default. 


You can work around this issue by changing where the variable is stored in the 
registry, or you can add the expected registry path before executing setx 
commands. To specify that the variable be set for system-wide use in HKLM 
rather than in HKCU, the default, add the /M switch to a setx command. To 
instead add the expected registry path, run reg add HKCU\Environment before 
executing setx commands. 


Breaking changes 


No breaking changes are included in this build. 
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